Existing networking and interconnect technologies have failed to keep pace with the development of computer systems, resulting in increased burdens being imposed upon data servers, application processing and enterprise computing. This problem has been exasperated by the popular success of the Internet. A number of computing technologies implemented to meet computing demands (e.g., clustering, fail-safe and 24×7 availability) require increased capacity to move data between processing nodes (e.g., servers), as well as within a processing node between, for example, a Central Processing Unit (CPU) and Input/Output (I/O) devices.
With a view to meeting the above described challenges, a new interconnect technology, called the InfiniBand™, has been proposed for interconnecting processing nodes and I/O nodes to form a System Area Network (SAN). This architecture has been designed to be independent of a host Operating System (OS) and processor platform. The InfiniBand™ Architecture (IBA) is centered around a point-to-point, switched fabric whereby end node devices (e.g., inexpensive I/O devices such as a single chip SCSI or Ethernet adapter, or a complex computer system) may be interconnected utilizing a cascade of switch devices. The InfiniBand™ Architecture is defined in the InfiniBand™ Architecture Specification Volume 1, Release 1.0, released Oct. 24, 2000 by the InfiniBand Trade Association. The IBA supports a range of applications ranging from back plane interconnect of a single host, to complex system area networks, as illustrated in FIG. 1 (prior art). In a single host environment, each IBA switched fabric may serve as a private I/O interconnect for the host providing connectivity between a CPU and a number of I/O modules. When deployed to support a complex system area network, multiple IBA switch fabrics may be utilized to interconnect numerous hosts and various I/O units.
Within a switch fabric supporting a System Area Network (SAN), such as that shown in FIG. 1, there may be a number of devices having multiple input and output ports through which data (e.g., packets) is directed from a source to a destination. Such devices include, for example, switches, routers, repeaters and adapters (exemplary interconnect devices). A set of switches, routers, repeaters and adapters interconnected by links is referred to as a subnet. Each subnet is managed by at least one Subnet Manager. A Subnet Manager (SM) residing either on an endnode or on an interconnect device and can be implemented either in hardware or software. A conventional subnet is not functional until it is configured by a SM. Specifically, a SM operates during the initialization process to discover the physical topology of the subnet, assign local identifiers to the endnodes and the interconnect devices, and establish possible paths among the endnodes. Based on these operations, the SM compiles various configuration information and loads this information into the subnet's interconnect devices, making them ready to handle network traffic.
One disadvantage of this approach is the necessity to load configuration information into an interconnect device each time a reset of the interconnect device occurs. This slows down the initialization process and requires additional bandwidth and processor resources to run the SM.
In addition, a problem with this approach arises when the SM resides on a server (or some other node) and data for booting the server resides on a storage device located across a network from this server. Because the IBA switch fabric is not functional until it is configured by the SM, the boot data cannot be transferred from the storage device to the server unless a network driver is available locally to activate the transmission and receipt of the boot data over the network. Accordingly, the SM itself cannot be initialized without an additional network driver residing on the server.